This modularisation track will be really beneficial, thank you!

Is the split between autoconfigure and starter modules necessary? I know that when Spring Boot started, the idea was to have an autoconfigure module separate from the starter modules so that users could build their own custom starters re-using the same autoconfigure module (one autoconfigure, multiple starters). I wonder if that's still a current requirement for Spring AI, considering there won't be a single autoconfigure module anymore.

For the sake of simplicity, I would consider moving the autconfiguration to the existing starter modules. So, for example, the Weaviate auto configuration would be placed in the spring-ai-weaviate-store-spring-boot-starter. Would that make sense?

There is a really good reason to keep it separate, but I’m embarrassed to say I can’t remember the argument presented to me. I think it along the lines keeping it separate is a better separation of concerns, I shouldn’t be forced to pick up autoconfig with a starter whose responsibility is dep mgmt. Let me sleep on it😁

@ThomasVitale,
The main reason to keep auto-configurations separate from boot starters is that you can compose auto-configurations but not boot starters. If auto-configurations are nested inside starter modules, they become unusable for composition.
So collocating auto-configs inside the starters doesn't seem a good idea.

Thanks for the explanation! That makes sense! I was more thinking about the "leaf" auto config (like "weaviate"), but I see that also in that case, if it ever needed to be composed into something else, having it inside the starter would be a limitation.